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IDL:  Background  and  Status 

1' 

Abstract.  This  paper  presents  an  overview  of  the  Interface  Description  Language 
(IDL).  We  describe  the  language  and  its  history.  We  aiso  discuss  the  status  of  the  IDL 
community. 

T 

1.  What  is  IDL? 

Programming  environments  contain  sets  of  tools  that  communicate  with  one  another.  Often  the 
shared  data  is  highly  structured  and  extremely  complex.  'The  Interface  Description  Language 
(IDL)  provides  a  mechanism  by  which  the  abstract  properties  of  complex  structured  data  may  be 
specified  precisely.  Abstract  specifications  can  be  mapped  to  multiple  target  languages  running 
on  many  kinds  of  computer  systems.  This  mechanism  pemnits  data  to  be  communicated  between 
programs,  or  parts  of  a  single  program,  safety  and  efficiently. 

The  range  of  existing  tool  communication  methods  can  be  illustrated  by  two  examples.  First,  one 
may  specify  a  singie  central  database  shared  by  ail  the  tools  in  the  environment.  This  approach, 
use  of  a  single  powerful  data  representation,  is  that  taken  by  the  Gandalf  programming 
environment  [4].  Alternately,  one  may  specify  a  particular  data  stmcture  as  the  interface  between 
each  pair  of  tools.  By  providing  a  powerful  mechanism  for  specifying  and  generating  data  stmc- 
tures,  IDL  enables  the  system  designer  to  tailor  toot  interfaces  to  specific  needs. 

Programs  in  which  interfaces  are  specified  in  fOL  communicate  by  means  of  reader/writer  pairs. 
An  interface  consists  of  a  reader,  which  gets  data,  a  writer,  which  sends  data,  and  some  ex¬ 
change  representation.  A  writer  transforms  data  in  the  internal  form  of  its  process  to  the  ex¬ 
change  representation.  A  reader  then  transforms  this  representation  into  the  internal  form  of  its 
own  process. 

IDL  supports  a  common  exchange  representation,  the  ASCII  External  Form.  This  form  can  de¬ 
scribe  data  from  any  IDL  specification  ind^ndent  of  language  or  machine,  but  it  is  often  in¬ 
efficient.  However,  in  practice  the  ASCII  form  serves  as  a  lowest  common  denominator  represen¬ 
tation.  An  IDL  translator  can  also  support  more  efficient  binary  exchange  forms. 

The  core  of  iDL  is  a  language  for  specifying  the  abstract  properties  of  data  structures.  The 
structures  specified  are  typed,  attributed,  directed  graphs.  Each  node  in  the  graph  has  a  collec¬ 
tion  of  attributes.  Attributes  can  have  types:  integer,  rationai,  boolean,  string,  set.  sequence, 
private  or  node.  Private  types  are  a  hook  allowing  the  tool  builder  to  specify  arbitrary  structures. 
The  nodes  form  a  graph  because  attributes  may  reference  other  nodes. 

IDL  defines  the  notion  of  a  class.  A  class  is  a  grouping  of  nodes  that  share  a  set  of  common 
attributes.  Operations  that  reference  only  these  common  attributes  may  be  defined  on  classes. 
The  class  mechanism  can  be  used  to  add  a  kind  of  generic  capability  to  target  languages  lacking 
such  capability.  Also,  classes  may  be  further  grouped,  fonning  a  class  stmcture.  An  extremely 
importartf  property  of  this  stmcture  is  that  it  need  not  be  hierarchical. 


An  IDL  translator  maps  an  abstract  IDL  specification  to  a  concrete  specification  in  some  target 
language.  In  building  a  translator,  a  number  of  issues  are  left  to  the  discretion  of  the  implemen¬ 
tor.  Among  these; 

•  How  does  the  IDL  type  model  map  onto  the  target  language? 

•  How  does  the  application  programmer  manipulate  Directs  within  the  IDL  type  model? 

•  How  much  njntime  support  is  generated? 

In  addressing  these  issues,  an  IDL  implementor  can  achieve  tremendous  leverage.  Since  it  need 
never  be  read  by  humans,  generated  code  may  be  written  in  an  unreadabie  and  unmodifiable 
style,  in  order  to  be  as  efficient  and  effective  as  possible.  I^urthermore,  generated  code  may  be 
arbitrarily  machine  and  language  specific. 

An  IDL  tool  presents  another  benefit  to  the  application  programmer.  In  general,  interfaces  to  data 
structures  and  mntime  support  constitute  a  sizable  portion  of  systems.  An  IDL  tool  will  generate 
this  code  correctly.  Furthermore,  the  runtime  support  may  use  highly-tuned  tools.  For  instance, 
beneath  the  type  manager,  one  could  put  a  highly-tuned  storage  manager  and  garbage  collector, 
which  then  would  be  incorporated  into  every  system  built  with  IDL.  When  an  entire  toolset  is 
based  on  IDL,  these  secondary  benefits  can  be  signfficant. 

In  addition  to  the  language  for  describing  data  structures,  IDL  contains  several  other  concepts. 
Among  these  Is  a  language  for  specifying  assertions.  This  language  allows  us  to  make  state¬ 
ments  about  data  stmctures  such  as  *all  the  back  pointers  in  a  data  stmcture  are  set  correctly." 
Another  piece  of  IDL,  the  process  model,  allows  us  to  make  statements  about  how  processes 
Interact,  such  as  "they  communicate  in  main  memory"  or  "they  pass  some  external  representation 
through  files."  Assertions  and  process  statements  give  us  more  information  to  reason  about 
systems  and  to  build  tools  to  support  interactions  among  pieces  of  systems. 

I  Finally,  IDL  is  formally  defined  in  denotational  semantics.  In  the  past,  this  has  had  a  very  prag¬ 

matic  effect.  Proposed  changes  and  implementation  decisions  were  weighed  against  the  require¬ 
ments  of  the  formal  definition.  In  the  long  run,  this  has  ted  to  a  cleaner,  more  coherent  language. 

2.  Histoiy  of  IDL 

I  The  Production  Quality  Compiler-Compiler  (POCC)  project  at  Camegie-Mellon  University  (CMU) 

'  [6]  developed  a  notation  called  LG  (for  Linear  Grapfii  to  describe  the  data  structures  passed 

between  phases  of  the  oompfler  [10].  The  project  also  developed  a  set  of  tools  for  processing  the 
notation.  However,  LG  had  a  number  of  drawbacks.  It  was  difficult  to  use,  and  It  was  strongly 
oriented  towards  the  particular  Implementation  language  (BLISS  [13])  and  host  machine  (the 
PDP-10)  used  by  the  PQCC  project.  Nonetheless,  It  was  a  very  useful  tool. 

I 

9 

^  At  CMU,  during  1979  and  1980,  a  consensus  developed  that  a  generalized  data  definition  lan¬ 

guage  was  needed  to  meet  the  needs  of  several  different  projects,  which  were  implemented  in 
different  languages  and  running  on  dWerem  computer  systems.  During  this  same  period,  the 
community  of  implemerfiors  of  the  Ada  programming  language  developed  a  strong  interest  in 
being  able  to  share  intermediate  program  representations. 
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In  late  1980,  there  were  two  major  candidates  for  a  common  intermediate  representation  of  Ada 
programs:  TCOL^,  developed  at  Carrwgie-Meilon  University,  and  AIDA,  developed  at  the  Uni¬ 
versity  of  Karlsruhe.  In  December  1980,  a  meeting  was  held  at  SofTech,  Inc.,  to  discuss  these 
two  representations:  at  this  meeting,  H  was  decided  to  try  and  merge  the  two  notations.  In 
January  1981.  a  one-week  design  session  was  held  at  Eglin  Air  Force  Base.  The  result  of  this 
meeting  was  a  new  Intermediate  representation,  Diana  [3]. 

As  a  shared  representation,  Diana  needed  precise  specification.  Previously,  John  Nestor,  David 
Lamb,  and  William  Wulf  had  defined  an  initial  design  of  IDL.  At  the  Eglin  meeting,  the  partic¬ 
ipants  revised  this  design  and  used  it  as  Diana's  specification  language. 

Soon  afterward,  the  IDL  reference  manual  [7]  appeared,  containing  the  first  version  of  the  formal 
definition.  This  was  followed  by  a  draft  revision  [8]  containing  only  minor  changes.  At  that  time, 
the  first  implementation  of  an  IDL  translator  was  built  at  CMU.  Later,  David  Lamb’s  PhD  thesis 
[5]  Investigated  the  practicality  of  using  IDL  to  build  large  systems  and  explored  many  of  the 
design  issues. 

In  1981,  Wulf  and  Nestor  founded  Tartan  Laboratories,  using  IDL  as  a  central  technical  basis  for 
their  compiler  building  tools.  Tartan  has  continued  to  support  work  on  IDL,  including  a  revision  of 
the  formal  definition  [1],  work  on  extensions  to  attrSxite  grammars  using  IDL  [9],  and  a  mntime 
system  built  by  Joseph  Newcomer. 

Several  other  sites  have  implemented  IDL  translators.  Intermetrics  has  two  implementations 
supporting  their  Ada  development  effort.  A  number  of  other  companies  building  Ada  compilers 
have  adopted  Diana  and  built  partial  translators  for  support.  More  recently,  a  Diana-like  language 
called  Ivan,  also  specified  in  IDL,  has  appeared  as  part  of  the  VHDL  system  [2]. 

Currently,  the  University  of  North  Carolina  at  Chapel  Hill  (UNC)  is  using  IDL  as  the  basis  of  an 
integrated  toolset  [11].  To  support  this  effort,  they  are  implementing  an  IDL  translator  targeted  to 
C,  Pascal,  Modula-2  and  Ada.  They  are  the  first  group  to  work  extensively  with  parts  of  IDL  other 
than  the  data  structure  description  language.  They  have  worked  with  both  the  assertion  language 
and  the  process  model.  Their  work  using  the  whole  of  IDL  Is  driving  many  of  the  changes  and 
extensions  currently  under  consideration. 

In  January  1986,  the  Software  Engineering  InstikJte  of  Camegie-Mellon  University  (hereafter  the 
SEI)  initiated  a  project  on  iDL  as  part  of  a  larger  focus  on  manipulation  of  data  in  programming 
environments.  The  major  product  of  the  project  wM  be  a  book  containing 

•  A  revised  language  reference  manual  incorporating  changes  and  extensions  to  IDL. 

•  A  guide  to  implemenlors  descrtoing  expertonces  and  containing  notes  about  im¬ 
plementing  IDL  efficiently  and  effectively. 

In  May  1988,  the  SEI  and  the  Computer  Science  Department  of  UNC  cosponsored  a  workshop 
on  IDL  The  workshop  brougM  together  people  have  been  signllicani  contributors  to  IDL  and 
IDL-B(e  technologies.  The  objective  was  to  exchange  ideas  and  open  Krtes  of  communication  for 
future  work. 


3.  Status  of  IDL 


In  preparation  for  the  IDL  workshop,  the  SEI  project  surveyed  a  number  of  users  and  implemen¬ 
tors  of  IDL  arKl  IDL-Hke  systems.  We  taked  to  fifty  people  and  gathered  names  of  about  one 
hundred  more.  From  them,  we  identified  thirteen  implementations  of  IDL  and  ten  impiemen- 
tations  of  IDL-Hke  systems.  TNs  work  oonvkiced  us  that  these  technologies  are  gaining  accep¬ 
tance  in  a  broader  section  of  the  community. 

We  see  three  issues  facing  the  IDL  community  today. 

•  To  make  IDL  more  aocesstrle. 

•  To  consider  a  number  of  ianguage  changes  arxf  extensions. 

•  To  coliect  and  disseminate  strategies  and  techniques  for  implementing  IDL. 

Until  recently,  the  only  available  introduction  to  the  concepts  of  IDL  was  the  language  reference 
manual.  As  a  part  of  their  system,  UNO  has  written  a  tutorial  [12]  that  provides  a  far  more 
coherent  introduction.  In  addition,  the  general  availability  of  a  tool  (the  UNO  system)  should  aid 
novices  in  gaining  a  full  appreciation  of  the  technology. 

A  number  of  people  currently  are  working  on  revisions  to  IDL.  After  some  years  of  experience 
with  the  ideas,  many  changes  and  extensions  to  the  language  have  been  proposed.  Most  of 
these  are  in  areas  outside  the  core  language;  for  example,  a  completely  revised  process  model 
has  been  proposed.  A  new  reference  manual,  to  be  published  as  part  of  the  SEI  book,  will 
incorporate  some  new  design  work  based  on  these  proposals. 

The  IDL  workshop  provided  a  fomm  In  which  to  discuss  proposed  language  changes.  Many  of 
the  participants  presented  new  work,  and  the  group  provided  a  great  deal  of  good  technical 
feedback.  As  work  on  the  new  design  continues,  a  new  Arpanet  mailing  list,  Info-IDL  (see 
announcement)  will  become  the  forum  for  this  discussion. 

A  major  reason  IDL  has  not  been  used  widely  in  the  past  is  that  strategies  for  implementing  such 
tools  efficienlly  are  not  obvious.  Experience  has  shown  that  there  are  a  number  of  practical 
engineering  iricks"  that  are  extremely  useful  Hr  building  an  IDL  system.  Discussions  with  the 
participants  at  the  workshop  confirmed  the  belief  that  ottier  implementors  have  discovered  their 
own  sets  of  tricks.  The  implemenlor's  guide  in  the  SEI  book  will  present  many  of  these  experi¬ 
ences,  tricks  and  strategies  in  a  framework  that  will  aid  future  implementors. 


I _ 
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